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[57] ABSTRACT 

A system and method for ensuring the security and integrity 
of applications and databases. The present invention pro- 
vides a user management system which allows permissive 
access to applications and stored procedures using a directed 
acyclic graph structure which allows users or groups of users 
to have the capability to access the desired applications and 
stored procedures. Also provided is a version control man- 
agement system which ensures a user is using the desired or 
current version of an application and also provides a frame- 
work for a developer to develop an application and install it 
on the system. 
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APPLICATION AND DATABASE SECURITY 
AND INTEGRITY SYSTEM AND METHOD 

RELATED APPLICATIONS 

This application is related by subject matter to the fol- 
lowing co-pending, co -owned U.S. Patent Applications: 
U.S. application Ser. No.08/405,766, filed Mar. 17, 1995, 
"Method and Apparatus for Transaction Processing in a 
Distributed Database System"; U.S. application Ser. No. 
08/579,371 filed Dec. 27, 1995, "Billing Statement Render- 
ing System and Method"; each herein incorporated by 
reference. 

TECHNICAL FIELD OF THE INVENTION 

This invention relates in general to maintaining the secu- 
rity and integrity of applications and databases. 

BACKGROUND OF THE INVENTION 

In the past, a user's access to applications has been 
controlled by the use of passwords. Generally, the password 
provides a user with access to all applications, with certain 
files, e.g., personal files, financial files, etc. being protected 
by a second password. More elaborate access control 
schemes have used access control lists for applications, 
databases, and systems. These access control schemes or 
systems have significant shortcomings, including that they 
are not very flexible for large user systems, users are 
provided access to applications and/or databases which are 
outside the scope of their work, and thus a user may disturb 
these applications or databases, and with password 
protection, the security may relatively easily be breached. 

With known systems and applications, there exist prob- 
lems with identifying and controlling which version of a 
particular application a user has access to and/or is using. In 
some systems, when a user is interfacing with another user, 
support personnel, etc., often it is required that the user 
verbally ask what version the other is using. Also in many 
cases, a new version is simply installed over the top of an old 
version, and new users access the new version automatically. 
This presents problems in that, if the new version has a 
significant bug, then the old version needs to be reinstalled, 
which is confusing and time consuming. Also, this does not 
allow the testing of the new version before it is installed to 
all users. 

With known systems and applications, problems exist in 
moving a particular application from a developer to the 
system. Typically developers customize their systems. This 
presents problems in moving the developed application from 
the developer to the system, particularly in relation to 
troubleshooting the application after it has been installed on 
the system. Also, problems exist with regard to transferring 
the files that are necessary for the application to run. 
Frequently, not all of the desired files are transferred, or the 
files are transferred in an undesired format. 

SUMMARY OF THE INVENTION 

In view of these and other shortcomings of the prior art, 
there is a need for a system and method which insures the 
security and integrity of applications and databases. 

It is an object of the current invention to overcome the 
above described and other shortcomings of the prior art. 

It is a further object of the current invention to provide a 
security system which is secure, flexible, and allows the user 
to access only those applications of stored procedures which 
are required for the user to do his work activity. 
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It is further an object of the present invention to ensure 
that a user is using the desired, current version of a particular 
application. 

It is another object of the present invention to provide a 
s framework that application developers use to facilitate trans- 
fer of the developer's work to the system. 

The present invention includes a user management system 
having a directed acyclic graph structure to provide a user or 
group permission to access applications, stored procedures, 
etc. The present invention also includes a version control 
management system which insures a user is using the 
desired current version of an application and provides a 
format for an application developer to facilitate the devel- 
opment and implementation of an application onto a system. 

BRIEF DESCRIPTION OF THE DRAWINGS 

A more complete understanding of the present invention 
and the advantages associated therewith may be acquired by 
20 referring to the accompanying drawings wherein: 

FIG. 1 is a block diagram depicting the architecture of one 
embodiment of a system for use in the present invention. 

FIG. 2 shows a simplified Directed Acyclic Graph (DAG). 

FIG. 3 is a flow chart illustrating, in a broad sense, the 
25 verification and access method utilized when a user attempts 
to access an application. 

FIG. 4 is a flow chart illustrating, in a broad sense, the 
version control management from the point of a user starting 
an application. 

FIG. 5 is a flow chart illustrating, in a broad sense, the 
version control management system from the application 
development and version release standpoint. 

DETAILED DESCRIPTION OF THE 
35 INVENTION 

The present inventive system and method is preferably 
utilized in a system having an architecture as shown in U.S. 
application Ser. No. 08/405,766, filed Mar. 17, 1995, entitled 
40 "Method and Apparatus for Transaction Processing in a 
Distributed Database System"; herein incorporated by ref- 
erence. FIG. 1 generally illustrates this system and archi- 
tecture. 

While the various aspects and embodiments of the inven- 

45 tion are capable of use in various systems and types of 
distributed database systems, for simplicity, the system will 
be described in connection with a Subscriber Management 
System (SMS) 100 having a distributed database. Such 
system is useful for, among other things, cable system 

so operations. However, the inventive system and method is not 
limited to this described system. As shown in FIG. 1, the 
SMS comprises a plurality of transaction generators labeled 
1 through N, where N=any integer. Each transaction gen- 
erator 120 is connected via a two-way communication link 

ss 105 to one (or more) data directory servers (DDS) 150. The 
present invention may include any number of data directory 
servers 150, but includes at least one. Each data directory 
server 150 in turn is connected via a two-way communica- 
tion link 165 to multiple data servers (DS^-Ds m ) 160. Each 

60 data server 160 is in turn connected to one or more databases 
either as components of a single subsystem (processor and 
database) or through a two way communication link 135. 
Additionally, each DDS 150 is connected via a two-way 
communication link 130 to one or more cross reference 

65 servers (X-refj-X-ref,,, where N=any integer) 170. 

FIG. 1 indicates a block of 1 through N, (where N=any 
integer) DDSs 150 representing DDS functionality within 
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the SMS. It is to be understood that, although not shown, 
connections between transaction generators 120 and DDSs 
150 as well as those between data servers 160 and DDSs 150 
are preferably individual connections rather than to a group- 
ing of DDSs. For example, Transaction Generator 1 is 
separately connected to each of the DDSs as is Data Server 
A. Alternatively, however, DDS functionality may be 
grouped with common connections to transaction generators 
120 and/or data servers 160 as indicated in FIG. 1 so long 
as proper control between DDSs 150 is maintained. 

Additionally, the SMS system 100 includes at least one 
control application 175 for communication between the 
DDS(s) 150 and a human operator and/or another SMS 
process. The control application 175 provides, among other 
functionality, a means for updating the internal rules used by 
the DDS(s) 150. 

When a transaction is generated by a transaction generator 
120 and sent to a data directory server 150, the data directory 
server 150 determines the appropriate server 160 for execu- 
tion of the transaction. Preferably, this is accomplished by 
the DDS 150 consulting the internal rules and identifying the 
arguments associated with the transaction. 

The SMS 100 of the present invention is designed to 
manage a very large number of On Line Transaction Pro- 
cessing (OLTP) transactions occurring within the system. 
The SMS 100 of the present invention provides users with 
the ability to query across the entire database from any client 
in the system. Similarly, each of the users may update data 
located anywhere within the SMS 100. 

The transaction generators 120 in the system of the 
present invention may be any devices capable of receiving 
input from a user and transmitting that input to the Data 
Directory Servers (DDSs) 150. This type of device is often 
referred to as a client and these terms are used interchange- 
ably herein. These devices may be dumb terminals (i.e., 
incapable of performing local processing) or they may have 
various processing capabilities of their own. Examples of 
transaction generators include, without limitation, PCS, 
RISC-based workstations and local area networks. In typical 
applications, there will be a large number of transaction 
generators 120. Thus, the SMS 100 is designed as an open 
platform environment which is hardware independent. The 
transaction generators 120 may be homogeneous in terms of 
interface and operation or they may be heterogeneous. In 
other words, all transaction generators 120 may be of one 
type or there may be a variety of devices interacting with the 
DDSs 150. It is also possible to permit customer interaction 
with the SMS 100 through an ARU/ANI (Automated Inter- 
active Voice Response Unit/ Automatic Number Indicator) 
(not shown). In this case, much of the processing may be 
driven by the telephone number retrieved by the ANI when 
the customer calls into the system. 

The DDSs 150 of the present invention function as the 
middle tier of a three tier client/server architecture. As 
illustrated in FIG. 1, more than one DDS 150 may exist 
within the SMS 100. In such case, each of the DDSs 150 has 
communication access to all of the other DDSs 150 as well 
as to each of the data servers 160. The DDSs 150 serve three 
primary functions. After receiving a client request, the 
selected DDS 150 first locates the appropriate server 160 for 
execution of the request, it then submits the client request to 
the selected server and finally the DDS 150 returns the result 
to the submitting client 120. 

Transaction generators 120 requesting information from 
the SMS databases must connect to a DDS 150 prior to 
accessing data. Through the use of internal rules, the DDSs 
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150 determine where a remote procedure should run in order 
to complete processing of a transaction. Access to the DDSs 
150 may be efficiently implemented through the use of 
remote procedure calls (RPCs) which are identified in tables 

5 internal to the DDS 150. Any of a large number of standards 
for such RPCs may be used with the current invention. 

The DDS(s) 150 are preferably open server applications 
that provide a mechanism to direct any data request asso- 
ciated with a generated transaction to a data server 160 that 

10 can service the transaction generators* requests. Specifically, 
the DDSs 150 may be open servers comprising the same or 
similar hardware as the data servers 160 of the present 
invention. Alternatively, the DDSs 150 may be configured 
differently from the data servers 160. The DDSs 150 func- 

15 tion to analyze the client's data request transaction and, 
based upon the transaction type and a set of rules, directs the 
request to the appropriate data server 160. The types of 
transactions which are received at the DDSs 150 are based 
upon a set of stored procedures recognizable to the DDSs 

20 150 and available to the transaction generators 120. The 
DDSs 150 communicate with a plurality of data servers 160 
each accessing one or more storage devices. In a preferred 
embodiment of this invention the data servers 160 are 
Sybase SQL (Structured Query Language) Servers which 

25 execute Sybase remote procedure calls (RPC). This inven- 
tion is not, however, necessarily limited thereto and the 
servers may be of any type so long as the stored procedures 
are designed for processing by the particular server and the 
associated database which are selected. It is possible to 

30 employ any number of servers 160, transaction generators 
120 and DDSs 150 in the SMS 100 of this invention so long 
as the proper number of communication channels can be 
supplied and supported. 

The data servers 160 maintain the customer data and are 

35 accessible by each of the transaction generators 120 through 
a DDS 150. In a typical implementation, the data servers 160 
are SQL devices which are capable of executing the RPCs 
transmitted by a DDS 150. The databases making up the 
enterprise can be either homogenous or heterogeneous. In a 

40 homogeneous environment, particular protocols for access- 
ing each of the databases are consistent throughout the 
enterprise. Conversely, in a heterogeneous environment, the 
particulars of database access vary within the enterprise. In 
a heterogeneous environment, it is often desirable, however, 

45 to render any differences in requirements within the enter- 
prise transparent to user working at the client site. That is, 
a user should not be aware of any database heterogeneity and 
a user request should be processed in a standard manner 
across all resources. 

The databases which are accessed in a distributed system 
may all be located together or they may be physically apart. 
They may be at the client location or they may be at an 
alternate site. Databases may be relational databases such as 

5S SYBASE (a trademark of Sybase, Inc.) or they may be as 
simple as a series of flat files. 

In FIG. 1, it can be seen that the DDSs 150 interface with 
a control application 175. The control application 175 func- 
tions to allow a system operator to store, update and modify 

60 stored procedures available to transaction generators 120. 
This is typically accomplished by downloading the update to 
the X-Ref Server 170 which loads the new rules base into the 
DDSs 150 at DDS startup. 
The SMS system also includes one or more X-Ref Servers 

65 170. The X-Ref Servers 170 function as a resource available 
to the DDSs 150 for determining where specific data resides 
in the system and for storing the rules base which is loaded 
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into the DDSs 150 at DDS start-up. The X-Ref Servers 170 11. Show whether a capability is: at the Root level (i.e. No 

contain a variety of global tables which are continually parent relationship), having only one link to the top or 

updated as data is added, updated and deleted within the having multiple parent relationships, 

system. "Capability" relates to an abstraction of access to system 

The present inventive system and method may be used on 5 resources. Capabilities are the means by which groups of 

the above described system or on any system having at least users are either granted or denied access to system services, 

one server and at least one database. The inventive appli- Capabilities are the means in which permissions are 

cation and database security and integrity system and assigned to system resources. Capabilities are also a means 

method includes The User Management System (TUMS) for extracting low level details into higher level entities that 

and Version Control Management (VCM). ™ managers can manipulate. Capabilities may contain capa- 

tu n \* «™# o.,<.t» m rnj\A^\ bilities which may in turn contain other capabilities. 

The User Managemen System (TOMS) FIG. 2 shows a simplified Directed Acyclic Graph (DAG). 

Hie User Management System (TUMS) uses a directed A Directed Acyclic Graph ^ a collection of nodes and 

acyclic graph mechanism to manage the users and their « edges" (lines) that connect them. As shown, the edges have 

authorization to execute specific applications. TUMS JS a ^ rectixm to them> u>| they are directed. The nodes contain 

includes two parts: user administration and capability the capabilities which may contain other capabilities. FIG. 2 

administration. The user administration part manages the includes nodes 1 through u . Nodes i through 6 represent 

authorized user details and generally provides the ability to: (he bwest leyel of detai] and afe generally individual stored 

1. Add a new user. procedures. A stored procedure is a single function that 

2. Remove an existing user. 20 executes on the database server, the lowest level of execu- 

3. Assign a user to a database group. tion control. The first grouping relates to collections of 
. j. c i j * u. stored procedures that perform some logical task. The higher 

4. Modify a user s database group. . r . r .... i i n.- u- l 

7 & r grouping relates to an application level. This hierarchy 

5. Modify a user's data such as FirstName, LastName, provides control over the permissions. Thus, the Directed 
LoginName, Password, default BusinessUnit, 25 Acyc]ic Gfaph provides a structure and means to set per- 
Department, JobType, PhoneNumber, list of applica- missio ns which control when a user can work with 
tions authorized to execute, etc. applications, tasks or stored procedures. 

6. Select a list of users who meet certain criteria, such as jhe directed acyclic graph requires at least two levels to 
clerks in a certain department. operate. Typically, the directed acyclic graph has between 

7. Modify the attributes of all the selected users. 30 two and five layers. 

The capability administration part manages the database Preferably, there is no access to raw tables. Database 

group attributes and authorizes permissions for the capabili- systems such as Sybase have the capability to turn off all 

ties. Capability administration provides the ability to: access to raw tables and require that a stored procedure be 

1. Add a new group by cloning from other groups. used to access it. It is preferred to use a stored procedure, 
. _ _ c . 35 since the stored procedure, utilizing the directed acyclic 

2. Modify the name of an ex.sting group. griph> ^ ^ ^ tQ ^ tQ whether ^ uscr 

3. Add a capability. ^ permission to access the raw tables via the stored 

4. Remove an existing capability. procedure. 

5. Make a capability to contain other capabilities, pro- It is preferred that individual users be grouped according 
vided they are not cyclic. (For example, A contains B, 40 to business unit, level of responsibility or authority, etc. 
B contains C. It is not allowed to have C contain A or Users are preferably grouped to simplify the task of man- 
B. The capability must go in one direction as aging permissions. It is preferred that a user belong to only 
A->B->C). one group. 

6. Assign execute permission, such as REVOKE or An example will help illustrate the structure and applica- 
GRANT database permission, to a capability. ^ tion of the Directed Acyclic Graph. Assume nodes 1, 2 and 

7. Propagate the execute permission to all the shared 3 P rovide permissions to low level stored procedures that 
capabilities (For example, in A-B-C relationship, relatc to readin S customer data > c ^ node * P rovldes thc 
A's GRANT permission will propagate that informa- permission to access a stored procedure which accesses a 
tion to B, and B will pass it to C). customer's name and address; node 2 provides the permis- 

„ _ . , , . . . , j , v- 50 sion to access a stored procedure which accesses the cus- 

to^"te l K« r Ste ™ ,om6r ' s bming M ° r[M,i ° n ; and node 3 p rovidcs the .p 6r - 

" ' " mission to access a stored procedure which accesses a list of 

products or services the customer uses. Assume nodes 3, 4 

A ^ R ^ c and 5 provide permissions to low level stored procedures 

55 which relate to writing customer data. Assume node 7 
provides permissions related to the task of reading customer 
data and that node 8 provides permissions related to the task 
of writing the customer data, e.g., billing customers. Thus, 
clerks in the accounting department may be granted permis- 
60 sions via nodes 7 and 8 which would allow them to access 
then, B is shared by 2 capabilities (A and Y). Suppose slored pr0C edures relating to nodes 1 through 5. Thus, 
A grants permission and Y revokes permission. In this TUMS would provide a group, such as accounting clerks the 
case, B gets grants permission because at least one of permission via nodes 7 and 8 to access the desired stored 
parent capability has Grant permission. procedures as noted above. 

9. Expand or collapse the shared capabilities from a given It would be desired that an accountant would have the 
capability. capability to access more stored procedures than the 

10. Locate any capability used in the graph. accounting clerks. Thus, an accountant may be granted 
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permissions via nodes 10 and 11 to access specific applica- 
tions relating thereto. This also allows the accountant to 
access the task granted permissions via node 9 and the stored 
procedure granted permissions via node 6, in addition to the 
tasks granted permissions via nodes 7 and 8 and the stored 5 
procedures granted permissions via nodes 1-5 which the 
accounting clerks are granted permissions to. Thus, the 
accountant would be granted access to the required 
applications, tasks and stored procedures to develop the 
accounts receivable, forecast, etc. This is in comparison to 10 
the accounting clerks who have a very limited access to 
applications and stored procedures. 

The directed acyclic graph method may be used in a 
variety of circumstances as illustrated by another example. 
For a cable system subscriber management system, assume 15 
that the customer service and sales representatives (CSSR) 
are divided into beginner, intermediate, and expert groups. 
The beginner group would be allowed to and be provided 
with permissions to access the stored procedures which 
allow them to order a movie for a customer or answer 20 
general questions. An intermediate group would be granted 
access to additional stored procedures to support a higher 
level of authority and additional work responsibilities, e.g., 
to sign-up a new user. An expert group would be granted the 
permissive right to access even more stored procedures 25 
consistent with a high level of authority, e.g., to zero out an 
account balance. 

Also, it may be advantageous to permit a user or group 
access to an application or stored procedure which reads and 
presents data, while not permitting access to an application 30 
or stored procedure which would update or otherwise 
change the data. 

For example, for an application which utilizes a graphical 
user interface (GUI), the application accessing a window(s) 
would be represented by a layer down from the application, 35 
i.e., to the right as shown in FIG. 2. If that window accesses 
other windows, then that represents another layer down. 
These windows would then access stored procedures, rep- 
resenting another layer down. Thus, in this example there 
would be at least four layers. 40 

As can be seen, the permissions trickle down, i.e., if a user 
has permissions as granted by node 10, he is also granted 
permissions as to nodes 1-5, 7 and 8. 

FIG. 2 is a very simplified directed acyclic graph. A large 
user system, such as a cable operations system, may have 45 
thousands of the nodes representing the lowest level of 
detail, generally individual stored procedures. 

Preferably, a group table is formed which includes all 
groups and is designed to interact with the directed acyclic 
graph. The group table is designed to lay permissions, i.e., 50 
apply yes or no values or grant or deny permission, to the 
DAG structure by group. 

In use, the directed acyclic graph structure is contained in 
a DAG table. Each time a stored procedure is run, the stored 
procedure, using login information, determines what group 55 
the user belongs to. The stored procedure calls the group 
table and causes the group table to be meshed with the DAG 
table. With this interaction of the group table and the DAG 
table, the stored procedure determines if the specific group 
is permitted to retain access to the stored procedure. If the 60 
specific group is not permitted to retain access to the stored 
procedure, the stored procedure does not continue to run. 

Thus, the group table interacting with the DAG table 
provides grant or denial of permission to retain access to 
each application, task, or stored procedure, as discussed 65 
above, on a group by group basis. This may be done by 
specifying a "Yes" (grant of permission) or "No" for each 
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node or by specifying a "Yes" with a default No. Also, as 
discussed above, the grant of permission flows to lower level 
nodes connected or related by the edges. 

The DAG structure and the group information is prefer- 
ably included in tables, i.e., the DAG table and the group 
table, as discussed above. However, the DAG structure and 
the group information may be incorporated and interacted in 
any suitable way. 

FIG. 3 shows the steps which occur with TUMS when a 
user tries to execute an application. First, that person* s 
LoginName is verified against a database. The person's ID 
and the application's ID are verified to see whether that 
person is authorized to execute the particular version of the 
application. If the person is not authorized to run the 
application, then he/she is not allowed to continue the 
session. Then, the person's LoginName and Password are 
used to get a connection to the desired database server. If that 
fails, the person is not allowed to query the database. Once 
the person gets proper connection to the database, that 
person's database group gets identified and verified. When- 
ever a query to the database is invoked through a stored 
procedure call, the application gets the database permission 
for the stored procedure using the person's database group. 
If the permission for that stored procedure is already granted 
to the group through TUMS, then the query is passed to the 
database. This is repeated for each stored procedure. If the 
permission for that stored procedure is denied or revoked for 
the group, then the query will not get passed to the database 
and this information is returned to the caller. If it is a 
Graphical User Interface (GUI) application, then, perhaps, 
an icon may set the look and feel accordingly (for example, 
the icon might get disabled if the permission is not granted). 
Once the query is completed, the results are returned to the 
user. 

A separate application, identified herein as 
"Security Client", whose purpose is to ensure that the secu- 
rity information is consistent, updated and distributed 
throughout the system is preferably used. Security Client 
works closely with TUMS and other password change 
windows. This application loops through all the servers and 
all the databases to replicate the changes made in the 
personnel or user_protects table. For example, when a 
user's password gets changed in TOMS, that change gets 
updated in the personnel table. The trigger will add a row in 
another table, security _update. The database's systems 
tables are preferably not updated at this time. Then, the 
Security Client application takes each entry in the security_ 
update table and updates the database's systems tables for all 
servers and databases. If for some reason, a server is down, 
then this application will make an entry in the security_ 
update table with the server information for future process- 
ing. This tool can be executed in the background and will run 
in a continuous mode. 

Version Control Management (VCM) 
Version Control Management (VCM) provides database 
security and is a means of ensuring data integrity. VCM 
provides a means for distributing applications over a 
network, controlling which version of an application a user 
is using, and ensuring that the user receives the correct 
version of the application. Also, VCM provides a technique 
which ensures that the set of files for an application are 
present and correct. While preferably VCM includes all of 
these aspects, each may exist independently of the others. 
VCM preferably includes two applications, identified herein 
as "Launch" and "VCMadmin". 

Generally, Launch is an application which ensures that a 
user is using a desired version of an application. The Launch 
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application involves the VCM system from the standpoint of required applications could still be run by directly executing 

a user starting an application. Generally, "Launch" is an the required applications. 

application which a user accesses during the login proce- It is preferred that each application must have the user's 

dure. Launch uses the user's name and password to connect name and password in order to log into a database. Rather 

to a server and, if it can't connect, first it presumes that the s than requiring the user to log in multiple times (once each 

user has mistyped his name or password. With the correct for Launch, the desired application, and any other applica- 

name and password, Launch connects to the server and asks tion the user wishes to use), Launch writes the user's name 

the server what set of applications the user is allowed to use. and password in a file, here identified as the 

Launch receives a list of applications that the user is allowed <application>.prf file. An application reads this file and uses 

to access. The user picks an application and Launch asks the 10 it to log into the database. Thus, with Launch, the user is 

server what version of the application is the correct version only required to log in once and does not have to keep 

for that user. These two steps may be combined into one logging in. 

query or may be two separate queries. Launch then provides The launch application then writes file <application>.prf 
an absolute path name to the application and executes that which preferably contains encoded user password and times- 
application as a parallel process. is tamp information. Preferably, this file is encoded to prevent 

Also, while a user is using an application, Launch checks other users from directly reading a user's password and 

to ensure that the user is using the correct version, i.e., that contains a timestamp to prevent other users from using 

a new version has not been released while the user is using another user's .prf file to gain access to the database, 

the application. Launch asks the server if there are any new The launch application then starts the file with the *Y* flag 

versions that are pending, i.e., if a new version has an 20 in parallel, i.e., this file runs in a non-blocking manner, i.e., 

effective date that is prior to the current date. If Launch the operating system will start the running of this file and 

determines that a new version exists, it downloads the return to the launch application without waiting for the 

application in the background. completion of the running of the file. 

Additionally, Launch makes sure that all the files neces- The file with the ( Y J flag looks for, reads, decodes, and 

sary for a particular application to run are present, the 25 checks the <application>. prf file. If the <application>. prf file 

correct size, and the correct permissions. For example, if a is not found, or if the timestamp is expired or corrupted, then 

file, necessary for an application, is accidentally deleted, it requires the user to login and provide the login informa- 

Launch would detect that this file was missing and tion. If the < applications prf file is okay, the file with the 'Y' 

re-download the missing file before it launches the flag begins execution of the desired application, the desired 

application, i.e., before the user has access to the application. 30 application is fully accessed, and the desired application 

Referring to FIG. 4, a user begins the application by queries the EXEC server for the application version that this 

typing "launch". This then brings up a logon screen and the user is supposed to be using and checks against the version 

user enters his logon information. The launch application currently being run. If the versions match, the running of the 

then connects with the EXEC server which queries for the desired application continues. If the versions do not match, 

set of applications the user is registered to use and presents 35 an error message is displayed and the desired application 

this set of applications to the user. Generally this is accom- exits. 

plished by using the user's ID and running a stored proce- This provides that if a user, e.g., a sophisticated user, is 

dure which joins two tables, one which involves information able to access and use an application without using the 

about all applications and the other which includes infor- launch application, that the user would be allowed to use the 

mation specific to the users. The user then chooses an 40 application only until a system administration personnel 

application from the presented list. The launch application determines that the user should be using a new version and 

queries the server for application information and the server takes the steps necessary to assign the new version to the 

returns the set of files for the version which the user is user. If a user were able to bypass launch, this would 

registered to use. otherwise avoid the automatic download and update part of 

One of the files is provided with a means for executing 45 the system. This provides that even if a user is able to bypass 

that file while the others will not be executed. For example, launch, eventually they will be converted to the desired 

execute (EXEC) flags can be used to execute this file, while version of the application. Thus, a user cannot execute an out 

not executing the other files. In this embodiment, to execute of date version which might possibly detrimentally effect the 

this file, the EXEC flag is set to 'Y*. Typically, the file with related databases. 

the EXEC flag set to ' Y' sets up the environment (so that the 50 Concerning the parallel running launch application, the 

desired application can find its support files) and then begins launch application queries for a pending version. If a pend- 

the execution of the desired application. Here, because the ing version exists, the launch application downloads the new 

desired application is made up of many files, the Launch version into the background of the user system. The new 

application needs to know which file to tell the operating version is downloaded into the background because the 

system to execute. The other files are generally support files, 55 downloading generally involves significant megabytes of 

used by the desired application for various purposes. Only data which could otherwise overload the system, 

the one file with the EXEC flag set to ' Y' is the "the file" to particularly, if it is an application which many users are 

execute. using, and because the downloading could take a significant 

The launch application then checks all of the received amount of time which would hurt the productivity of the 

files in the set for correct size and permissions. If a file(s) is 60 user. 

of an incorrect size, incorrect permission or otherwise The downloaded application preferably remains in the 

unacceptable, the launch application downloads from the background until a system administration person decides 

server a new file(s) with the correct size and permissions. that the applicable group should be using the new version. 

Each application that may be launched (by launch) is a There are generally two reasons why it preferably takes user 

separate, stand-alone application. It is preferred that each 65 action to replace the old version with the new version and 
application have the ability to be executed independent of why this is not done automatically. First, the system may be 
Launch, such that if Launch were to have a fatal bug, the used in a franchise arrangement. Usually, the franchisee 
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likes to retain control of what version of an application is The support files include resource files, run files, and 

being used. Frequently, the franchisee will wait until he possibly other files depending upon the application. The 

knows that another franchisee has tested the new version of creation of these files may involve third-party software or 

the application and that it has worked satisfactorily. It is may be scripts that a developer has written, 

desirable that the franchisee retain the flexibility to operate 5 The execution of VCMadmin-iregister.src leads into the 

either the old version or the new version. *f xt P rocess ste P> insertion of the executable and its support 

Secondly, often there is a "cut over date", i.e., a specific files into server. VCMadmin is an application and 

date, when a new version of a database is to be released. register.src is an argument to the application. The -i is a 

Typically, it is desired to cut over related applications and fla S t0 indicate initialization. 

j ; i_ * t u *• i ** u j ^ The application then shows a login screen and the CM 

database* at 10 ^ mformalion t0 ^ me app i ication l0 

the database or vice versa. Both the applications and the ^ ap pi ication rea ds, parses register.src and 

databases need to be released almost simultaneously. In this insem tfae application and support mes int0 me EXEC 

case, even though the new version of the application is servef Here> the CM ^ provide an effective date of the 

available, its desired that the system personnel administrator developed application far into the future to avoid any 

would set the effective date for the user for the date when the 15 indication that this is a pending version, 

new version is to be cut over. Next, the CM informs quality assurance (QA) of this new 

VCM admin is an application that inserts newly developed version. The QA modifies the "apps.users" table using 1SQL 

applications or versions into the system. The VCMadmin to allow a tester to test the new application. The tester gains 

application provides a mechanism for presenting applica- access to the new version using the launch application as 

tions or new versions that are developed by developers to the 20 discussed above. The tester determines whether the new 

users in an official way which maintains the ability to version is suitable for release to the field. If it is not, the 

troubleshoot the application after its release. VCM provides developer may modify the program as discussed above. If it 

a framework that the application developer takes advantage is suitable for release to the field, the CM changes the 

of to automate the process of building a control version and effective date to "today", then, through TUMS and the 

distributing it to the users. Generally, VCMadmin will only 25 launch application, the new version is distributed to users 

be used by Control Management (CM) personnel or by the P ursuant to the launch application as discussed above. Here, 

° a system personnel administrator uses TUMS to register 

individual developers uge ^ Qew ^ ^ wheQ ^ next 

FIG. 5 shows a flow diagram of the version control ^ ^ ^ &M 

management from the standpoint of a developer developing M q{ ^ Qew yersion installation> old versions 

a new version of an application. To initiate this, the devel- 30 should eventually be purgcd- However, early in the new 

oper types "make install", a utility program with the target version instaUation process , care should be taken to ensure 

install. The install target allows: mat two versions, i.e., the new version and the just replaced 

1. The building of the application. version, are always available in the event that a catastrophic 

2. The creating of a file that contains the entire release (a failure in the new version requires a "roll back" to the just 
'tar* file) 35 replaced version. 

3. The mailing to a configuration management (CM) present invention, with TUMS (which utilizes a 

person informing him that a new release is available. ***** ^ VC ™: 

_ , )jC1 , ... ~ itt ttkttv ♦Tf..\ mentioned above by providing a higher level of security, 

The 'tar' file (abbreviation of "tape archive-a Ur^X utility) fle ^ aUow X P missior | to u | ers as desiredf an / a 

contains all of the source code, ^ader r^urce, stored ^ structur / which ^ the user to only see thosc app i ication 

procedure definitions, a makefile, README file, and any Qr stored procedures which tne user ^ expected to use. The 

other files necessary for the application to build and execute. present invcnt j on ^ so i vcs the problems mentioned above 

A tar file provides a file format whereby many files are relating to users not using the correct version of an appli- 

concatenated together to form a single file. It is used to make cat j on by providing the launch application which ensures 

moving a set of files around simpler and less error prone, ^ mat are using the desired version of an application. 

since one needs to move only the tar file and "untar" it in Further, the present invention overcomes shortcomings 

order to get all of the files in the set, relating to developing new versions by providing a means to 

The CM executes a "pull" script which: install a new version on the system and test it on the system 

1. copies the 'tar' file to a known area, and prior to releasing it to the users. 

2. uncompresses, "untars" the 'tar' file into a format 50 Although the present invention has been described in 
which documents the file and which includes a human detail, it should be understood that various changes, 
readable format. alterations, and substitutions may be made to the teachings 

The CM then executes "cm.sh", a script, which sets up the herein without departing from the spirit and scope of the 

environment for the CM. The CM executes "make cm", a present invention as defined by the appended claims, 

utility with a target "cm". The cm target: 5S What is claimed is: 

1. Builds the executable, setting VCM flag. 1- A method of controlling access to applications on a 

2. Builds support files. s y slem havin S a data server ' com P risin g the ste ps °^ 

3. Executes VCMadmin-iregister.src. obtainin S a user identification entered by a user; 
Each application has an executable (sometimes called the accessing a selected application on the data server; 

program). In order for the application to behave as desired, 60 accessing a file having data comprising a directed acyclic 

it must be built in such a manner that the queries to ensure graph structure, said directed acyclic graph structure 

that the user is using the correct version of the application having at least two levels of nodes, each node providing 

are enabled. This is done using a build flag (sometimes for indicating the grant or denial of permission to 

called a define), here called "VCM". Building of the appli- maintain access to a specific application; 

cation involves using the compiler to compile the header/ 65 determining whether the user is authorized to maintain 

source files into object files and the linker to link object files access to the selected application using the user iden- 

and library archives into an executable. tification; 
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obtaining a set of files for a version of the selected 
application that the user is permitted to use; 

initiating the selected application using the files obtained; 
and 

checking for pending versions of the selected application 5 
during execution of the selected application. 

2. A method of providing a user with a latest version of a 
selected application in a system having at least one data 
server, comprising the steps of: ^ 

obtaining a user identification entered by a user; 
determining which applications the user is permitted to 
use; 

obtaining a selection entered by the user of an application 

the user is permitted to use; 15 
determining which version of the selected application the 

user is permitted to use; 
obtaining a set of files for the version of the selected 

application that the user is permitted to use; ^ 
initiating the selected application using the set of files 

obtained; and 

checking for a version of the selected application that is 
more recent than the version of the selected application 
which has been initiated, wherein the step of checking 2 s 
is carried out during execution of the selected applica- 
tion. 

3. The method of claim 2, comprising the step of down- 
loading a new version of the selected application which is 
more recent than the version of the selected application 30 
which has been initiated. 

4. The method of claim 3, wherein the new version of the 
selected application is downloaded in the background. 

5. The method of claim 2, wherein the step of checking for 

a more recent version of the selected application is carried 35 
out by an application running in parallel with the selected 
application. 

6. The method of claim 2, wherein the step of checking for 
a more recent version of the selected application is carried 
out by the selected application. 40 

7. The method of claim 2, comprising the step of termi- 
nating access to the selected application if there is a version 
of the selected application which is more recent than the 
version of the selected application which has been initiated. 

8. A method of developing a new version of an application 45 
on a system while an old version of the application is 
running on the system, wherein the system has at least one 
data server, comprising the steps of: 

initiating a utility application on the data server; 
building a new version of the application in the utility 50 
creating a tar file which contains the new version of the 
application; 

copying the tar file to a predetermined area and in a 
predetermined format; 5S 

testing the new version of the application in the copied tar 
file; and 

releasing the tested new version of the application to a 
user, 

wherein the tar file contains a source code and a set of files 60 
for building and executing the new version of the 
application. 
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9. A method of developing a new version of an application 
and providing that a user uses the new version of the 
application when selected in a system having at least one 
data server, comprising the steps of: 

creating a tar file which contains the new version of the 
application on at least one data server; 

copying the tar file to a predetermined area in a prede- 
termined format; 

testing the new version of the application in the copied tar 
file; 

obtaining a set of files for the new version of the appli- 
cation if the user is permitted to use the new version of 
the application; 
initiating the application using the files obtained; and 
checking the initiated application for pending versions 
during execution of the initiated application. 

10. A method of controlling user access to system 
resources, comprising the steps of: 

obtaining an identification of a user; 

obtaining a request of the user to initiate a resource access 

function for accessing a resource; 
determining if the user is permitted to initiate the 

requested resource access function, including the sub- 

steps of: 

accessing a directed acyclic graph structure, said 
directed acyclic graph structure having a plurality of 
capabilities arranged in a plurality of levels, wherein 
each capability of a lowest level represents a per- 
mission to perform a corresponding resource access 
function, wherein each capability of successively 
higher levels contains at least one capability of a 
preceding level, and wherein each capability of a 
highest level is granted to at least one user, and 

using the identification of the user to determine which 
capabilities the user is granted in accordance with the 
directed acyclic graph structure; and 
performing the requested resource access function if it is 

determined that the user is permitted to initiate the 

requested resource access function. 

11. The method of claim 10, wherein there are at least two 
users and the users are grouped into at least two groups and 
wherein at least one capability is granted to each group in 
accordance with the directed acyclic graph structure. 

12. The method of claim 11, wherein information relating 
to the groups of users is included in a group table and 
information relating to the directed acyclic graph structure is 
included in a directed acyclic graph table. 

13. The method of claim 11, wherein each user is a 
member of one group. 

14. The method of claim 10, wherein a capability of a 
given level contains two capabilities of an immediately 
lower level. 

15. The method of claim 10, wherein the resource is a 
database. 

16. The method of claim 10, wherein the resource access 
function includes reading data in the database. 

17. The method of claim 10, wherein the resource access 
function includes writing data to the database. 

* * * * * 
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